To implement deployment flexibility and manageability of network elements, the industry proposes a software-defined networking (SDN) concept. SDN decouples control logic of the network elements from their forwarding functions, and deploys the control logic of all the network elements in a centralized manner, so that control and maintenance work of a network can be simply implemented by performing an operation on a control plane device. Therefore, management efficiency of the network is increased, a forwarding plane device is simpler, and high performance and reusability of the forwarding plane device can be easily achieved.
In actual application, an SDN network generally includes a controller that functions as a control plane device and a forwarder that functions as a forwarding plane device. The controller uses processing rules of the forwarder to perform control on a data packet processing process. Each processing rule includes match field information and an instruction set including one or more action instructions. The match field information is used to determine a to-be-matched data packet, that is, a data packet corresponding to the processing rule. The instruction set is used to instruct to perform, according to an action instruction in the instruction set, processing on the data packet corresponding to the processing rule. Each action instruction optionally includes an action type and an action parameter. The action type and the action parameter are collectively referred to as an action variable of an action instruction in the present disclosure. Usually, the processing rule may further include an identifier or an index of the processing rule. The match field information of the processing rule and the identifier or index of the processing rule may be referred to as rule description information of the processing rule. The rule description information of the processing rule may be used to identify the processing rule. It should be noted that, the rule description information being used to identify the processing rule does not necessarily mean uniquely identifying a processing rule. Different processing rules may have same rule description information.
The OpenFlow protocol is a most typical and most widely applied protocol in an SDN network. Network elements in the OpenFlow protocol include an OpenFlow controller and an OpenFlow forwarder (Openflow Switch), which are respectively referred to as an OF controller and an OF forwarder for short below. Data packet processing in the OpenFlow protocol is performed based on a service flow granularity. Each service flow may be represented by a combination of different packet header fields, such as a source Media Access Control (MAC) address, a destination MAC address, a source Internet Protocol (IP) address, a destination IP address, a source port number, and a destination port number. The OF forwarder stores a processing rule of the flow granularities in a flow table of the OF forwarder. Therefore, a processing rule in the OpenFlow protocol is also referred to as a flow entry. The following Table 1 shows a structure of each flow entry.
TABLE 1Match FieldPriorityCounterInstructionsTimeoutCookie
Each flow entry includes a match field, a priority, a counter, an instruction set, a timeout, a cookie, and the like. The match field may be considered as rule description information of the flow entry. The instruction set includes an action instruction corresponding to the flow entry. An action variable of each action instruction includes an action type and an action parameter. In this case, the rule description information may further be used to determine a data packet corresponding to the processing rule, and the data packet corresponding to the processing rule accords with the rule description information.
When the OF forwarder receives a data packet of a user, the OF forwarder matches the data packet with a match field of each flow entry. The OF forwarder then performs, according to a successfully matched flow entry, an action included in an instruction set on the data packet. In this way, forwarding, modification, and other control processing of the data packet are implemented.
The OpenFlow protocol uses a flow modification (Flow_mod) message for addition, modification, and deletion of a flow entry. A main structure of each Flow_mod message is as follows: Flow_mod={message type (MsgType), table ID, match rule, Instructions (Action 1, Action 2, . . . Action n)}. When a flow entry is being modified, the Flow_mod message includes an identifier that Msg_Type is Modify or Modify_Strict to respectively indicate non-strict match modification and strict match modification on the flow entry. Strict match modification is to change an instruction set of a flow entry whose match field is completely the same as a match rule carried in a Flow_mod message to an instruction set carried in the Flow_mod message. Non-strict match modification is to change instruction sets of all flow entries whose match fields are covered by a match rule carried in a Flow_mod message to an instruction set carried in the Flow_mod message. A difference between the two types of modification is illustrated below.
For the following three flow entries stored in a flow table (the following examples and embodiments to be described provide only some content of flow entries related to this disclosure, and other fields, such as timeouts and cookie, are irrelevant to the present disclosure and are not listed herein):
flow entry 1: match rule (Match rule) (src_ip=ip1, dst_ip=ip2, protocol=TCP, dst_port=80), instructions (action1, action4);
flow entry 2: Match rule (src_ip=ip1, dst_ip=ip2, protocol=UDP, dst_port=53), instructions (action2, action4); and
flow entry3: Match rule (src_ip=ip1, dst_ip=ip2), instructions (action3, action4).
It is assumed that information carried in a Flow_mod message is: Msg_type, match rule (src_ip=ip1, dst_ip=ip2), instructions (action4, action5). If Msg_Type carried in the Flow_mod message is Modify_Strict, instructions in the flow entry 3 are replaced with instructions (action4, action5) because only the flow entry 3 completely matches the match rule carried in the Flow_mod message; if Msg_Type carried in the Flow_mod message is Modify, instructions in the flow entries 1, 2, and 3 are all replaced with instructions (action4, action5) because the match rule in the Flow_mod message is included in all the flow entries 1, 2, and 3.
It can be learned from the foregoing description and examples that one or more flow entries can be modified in batches by means of strict match modification or non-strict match modification in a flow entry modification method defined in the OpenFlow protocol. However, the modification is limited only to complete replacement of an original instruction set of a flow entry with an instruction set carried in a Flow_mod message.
This modification method is excessively inflexible, leads to low modification efficiency in most cases, and occupies more communication resources between an OF controller and an OF forwarder.